<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <title>Eclipse (Platform, JDT, PDE and Equinox) Release Engineering Build Schedule</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <link rel="stylesheet" href="https://www.eclipse.org/default_style.css" type="text/css">
  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <h2 id="schedule">Eclipse Release Engineering build schedule</h2>
    <h4>Platform, JDT, PDE:
      <a href="http://download.eclipse.org/eclipse/downloads/">Downloads</a>,
      <a href="https://www.eclipse.org/eclipse/development/">Plans</a>;
      Equinox:
      <a href="http://download.eclipse.org/equinox/">Downloads</a>,
      <a href="https://projects.eclipse.org/projects/rt.equinox/next-release">Plans</a>.
      See also the <a href="https://wiki.eclipse.org/Simultaneous_Release">Simultaneous Release</a> plans.
    </h4>

    <font class="indexsub">Last change of static content: 2018-09-20.</font>

    <p>
    I-builds use branches specified in <a href="https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/production/streams/repositories_master.txt">repositories.txt</a> file, from
    master branch of aggregator (eclipse.platform.releng.aggregator). The projects built are submodules of aggregator so normally
    there is one line in repositories.txt file for each submodule of the aggregator.
    <br>&nbsp;&nbsp;&nbsp;(daily 18:00 <a href="https://en.wikipedia.org/wiki/Eastern_Time_Zone">Eastern Time</a>, EST/EDT, -0400/-0500)
    </p>

    <p>
    <a href="https://calendar.google.com/calendar/ical/prfk26fdmpru1mptlb06p0jh4s%40group.calendar.google.com/public/basic.ics">ICAL Calendar URL</a>
    </p>

    <iframe src="https://calendar.google.com/calendar/b/1/embed?mode=AGENDA&amp;height=600&amp;wkst=1&amp;bgcolor=%23FFFFFF&amp;src=prfk26fdmpru1mptlb06p0jh4s%40group.calendar.google.com&amp;color=%23B1365F&amp;ctz=America%2FNew_York" style="border-width:0" width="800" height="600" frameborder="0" scrolling="no"></iframe>
    <h4 id="rebuilds">Rebuild Policy</h4>
    <ul>
      <li>Mondays' integration builds - rebuild if compile errors, missing plug-ins, the build is unusable, or if the drops do not get posted.</li>
      <li>Other integration builds - rebuild on request for serious or urgent issues.</li>
    </ul>

    <br>

    <h4 id="retention">Build Retention Policy</h4>

    <p>In an effort to reduce our disk utilization on the eclipse.org infrastructure and reduce the amount of data sent to the mirrors, we have adopted the following build retention policy.</p>
    <ul>
      <li>Release builds are kept indefinitely and moved to the archive.eclipse.org server as appropriate.</li>
      <li>The last four integration builds are retained in the I-build repository.</li>
      <li>Mondays' integration builds are retained until the release is available.</li>
      <li>Stable builds are retained until a release is available.</li>
    </ul>

    <br>

    <h4 id="notes">Build Notes</h4>

    <strong>For the 4.<i>&lt;n&gt;</i> Mondays' integration builds: </strong>
    <ul>
      <li>Build time is 18:00 (Eastern time).</li>
      <li>In the event of an integration build failure due to compile errors, missing plug-ins, or if the drops are not posted,<br>there will be a same day rebuild upon
      submission of a fix.</li>
      <li> In the event of multiple integration build failures due to problems in the submission (i.e. not infrastructure problems),
        <br>all other work will stop until guaranteed-to-be-successful build contributions are prepared for a rebuild.</li>
    </ul>

    <br>


    <p>In the above descriptions, a build is considered to be a failure if there are &quot;Red X&quot;s that the developers
    agree represent valid reasons for them to not begin using the integration build.
    An example of a Red X which would *not* require a re-build would be a test which
    failed because the test was bogus. </p>

    <p><strong>IMPORTANT</strong>: Committers are expected to run tests before pushing changes to master or a maintenance branch.
    In addition, teams should track test failures to detect
    integration problems early on. What we want to achieve is for the Monday
    4.<i>&lt;n&gt;</i> I-build to typically be successful, with an infrequent requirement for a rebuild.
    Failing builds until Wednesday should be treated as a catastrophic
    failure. In other words, more than two or three of these per year is an unacceptable
    failure rate. </p>

    <h4 id="milestones">Milestone Weeks</h4>
    Here's the usual schedule for milestone weeks:
    <ul>
      <li>Monday: Last day of development (and even then, no "big changes"). After Monday 20:00 ET, no feature work or unrelated fixes are allowed -- only regression fixes.</li>
      <li>Tuesday: All-day test pass. Nobody should develop or fix anything. Literally spend the entire day testing.</li>
      <li>Wednesday: Fix day with a focus on fixing regressions found during the test day (Tuesday). No unrelated fixes. Review and thoroughly test all commits.
        <ul>
          <li>The last Wednesday build is the release candidate every team signs off on Thursday.</li>
          <li>The "New and Noteworthy" entries are due on Wednesday evening:<br>
              Git repo: <code>ssh://git.eclipse.org/gitroot/www.eclipse.org/eclipse/news.git</code><br>
              Gerrit: <code>ssh://git.eclipse.org:29418/www.eclipse.org/eclipse/news.git</code><br>
              Live website: <a href="https://www.eclipse.org/eclipse/news/4.10/">https://www.eclipse.org/eclipse/news/4.10/</a></li>
        </ul>
      </li>
      <li>Thursday: Sign-off after re-testing, or at least confirming no changes have been made to your component's code since the last time the component was tested well.</li>
      <li>Friday: Build is officially declared and made available.
        <ul>
          <li>The master branch stays closed until the milestone is officially released. (That is, it is not enough that your component has signed off.)</li>
        </ul>
      </li>
    </ul>

  </body>
</html>
